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ABSTRACT 

This  analysis  examines  the  sealift  execution  scheduling  process  with  the  purpose  of 
identifying  factors  which  require  consideration  in  the  development  of  an  automated 
execution  scheduling  system.  Organizational,  communicational,  and  algorithmic  factors 
are  examined  and  assessed  as  to  importance  in  scheduler  development.  From  this 
assessment,  a  proposed  system  structure  is  developed  to  provide  a  high  level  framework 
upon  which  further  research  and  development  can  be  built.  Recommendations  for  interim 
improvement  in  the  process  are  made  as  well. 
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I.  PROBLEM  INTRODUCTION 

A.      BACKGROUND 

Strategic  sealift  is  a  major  factor  in  the  response  and  mobilization  capability  of  this 
nation's  armed  forces.  In  a  major  operation,  sealift  will  account  for  90-95%  of  cargo 
movement  [Ref.  l:p.  4-1].  Recognizing  the  importance  of  such  a  capability,  the 
Secretary  of  the  Navy  has  designated  strategic  sealift  as  a  primary  mission  area.  The 
command  responsible  for  directing  and  managing  the  successful  accomplishment  of  the 
strategic  sealift  mission  is  the  Military  Sealift  Command  (MSC).  MSC's  responsibilities 
include  both  deliberate  planning  and  execution  aspects  of  strategic  sealift  employment. 
Also  tasked  with  ensuring  the  effective  use  of  sealift  and  all  transportation  resources  is 
the  United  States  Transportation  Command  (USTRANSCOM).  Established  in  1987  as 
suggested  by  the  Department  of  Defense  Reorganization  Act  of  1986  (commonly  referred 
to  as  the  Goldwater-Nichols  Act),  USTRANSCOM  is  a  joint,  specified  command 
responsible  for  transportation  missions,  responsibilities,  and  the  forces  of  the  three 
Transportation  Operating  Agencies  (TOAs),  Military  Traffic  Management  Command 
(MTMC),  Military  Airlift  Command  (MAC),  and  MSC.  In  a  peacetime  environment, 
USTRANSCOM  centers  its  efforts  upon  developing  and  evaluating  wartime  planning  and 
execution  procedures.  It  does  not  direct  the  administration  of  routine  peacetime  military 
transportation.  However,  in  a  deployment/execution  environment,  USTRANSCOM 
assumes  operational  command  of  all  three  TOAs  and  directs  the  employment  of  all 
strategic  transportation  resources.  So,  in  an  execution  scenario,  MSC  schedules  sealift 
under  the  control  of  USTRANSCOM. 


B.  SEALIFT  CHARACTERISTICS 

Sealift  is,  by  structure  and  nature,  a  difficult  process  to  manage.  There  is  no  large 
dedicated  sealift  force  available  in  place  as  there  is  with  airlift.  Therefore,  the 
composition  of  the  sealift  base  that  MSC  will  have  to  draw  on  is  determined  primarily  by 
private  sector  economic  factors.  Such  factors  include  labor,  construction,  and  operating 
costs  as  well  as  commercial  usefulness  and  taxes.  As  a  result  of  these  factors,  sealift 
ships  tend  to  vary  a  great  deal  in  such  characteristics  as  speed,  range,  capacity,  mission, 
and  military  usefulness.  These  economic  factors  have  also  reduced  the  size  of  the  U.S. 
commercial  fleet  with  large  portions  of  the  world  commercial  fleet  sailing  under  foreign 
flags  of  convenience.  The  net  effect  of  the  military  usefulness  and  flag  of  convenience 
factors  is  to  put  sealift  schedulers  in  the  position  of  having  to  manage  an  extremely  scarce 
resource.  Also  impacting  this  scarcity  are  the  speed  and  range  factors.  At  best,  a  given 
ship  can  make  an  Atlantic  transit  to  Europe  in  seven  to  ten  days.  The  transit  times  are 
much  greater  for  Pacific  transits.  This  reduces  the  availability  of  ships  for  multiple  lifts, 
especially  if  a  ship  is  on  the  low  end  of  the  speed  range.  These  considerations  all 
culminate  in  the  determination  that  sealift  execution  scheduling  must  be  done  intelligently 
and  efficiently  to  derive  the  maximum  benefit  from  scarce  resources. 

C.  DEVELOPMENTAL  PRIORITIES 

While  great  attention  and  resources  have  been  applied  to  deliberate  planning 
processes  and  systems,  little  effort  has  been  applied  to  execution  scheduling.  Deliberate 
planning  centers  around  developing  a  concept  of  operations  for  an  operation  plan 
(OPLAN)  and  validating  the  requirements  and  feasibility  of  that  plan.  Conceivably,  the 
information  developed  for  that  OPLAN  could  be  drawn  upon  in  an  actual  crisis,  and,  with 
appropriate  modification,  be  used  for  execution.  The  problem  is  that  while  deliberate 
planning  systems  have  been  developed  and  improved,  little  effort  has  been  devoted  to 
developing  and  improving  the  execution  scheduling  systems  necessary  to  realize  the 


objectives  of  those  OPLANs.  Execution  scheduling  is  still  largely  a  tedious,  manual 
process,  completely  different  from  the  deliberate  planning  process.  If  the  deliberate 
planning  process  is  to  have  any  real  value,  an  equally  effective  execution  scheduling 
process  must  be  established. 

D.      PURPOSE  AND  METHODOLOGY 

The  purpose  of  this  analysis  is  to  examine  and  define  the  sealift  execution 
scheduling  problem  in  order  to  provide  a  framework  upon  which  an  effective  scheduling 
system  can  be  developed.  The  factors  to  be  examined  include  the  actual  execution 
process,  existing  systems,  interfaces,  and  system  requirements.  From  this  examination, 
a  broad,  high  level  system  structure  will  be  proposed.  This  structure  will  not  be 
sufficient  in  detail  to  begin  system  development.  It  will  be  sufficient  to  direct  further 
research  into  subareas  of  the  execution  scheduling  problem.  The  hope  is  that  such 
research  will  eventually  culminate  in  an  effective,  automated  scheduling  system. 


II.  EXECUTION  PROCESS  DESCRIPTION 

A  sealift  operation  is  a  massive  undertaking.  Even  so,  it  is  but  a  subfunction  of  an 
entire  process  known  as  the  Crisis  Action  System  (CAS).  This  system  is  implemented  in 
crisis  situations  where  time  constraints  are  of  great  significance  [Ref.  2:p.  209].  These 
situations  are  further  delineated  as  follows: 

•  Time  available  to  plan  the  operation  is  limited  to  only  a  few  days  or  weeks; 

•  Timely  identification  of  resources  is  necessary  to  prepare  forces,  transportation, 
and  supplies; 

•  Actual  movement  and  employment  of  forces  is  expected  in  the  immediate  future. 

The  purpose  of  CAS  is  to  enable  the  Joint  Deployment  Community  (JDC)  to  plan, 
deploy,  and  employ  U.  S.  military  forces  in  an  organized  and  expedient  manner  in  a 
relatively  short  period  of  time.  These  procedures  are  keyed  upon  effective  use  of 
whatever  time  is  available,  rapid  and  effective  communications,  and  use  of  previous 
planning  wherever  possible.    CAS  is  composed  of  the  six  following  phases: 

I.  Situation  Development 

II.  Crisis  Assessment 

III.  Course  of  Action  Development 

IV.  Course  of  Action  Selection 

V.  Execution  Planning 

VI.  Execution 

All  participants  in  the  process  have  specific  responsibilities  and  goals  for  each 
phase.     However,  it  should  be  noted  that  in  a  time-sensitive  situation,   significant 


compression  of  the  above  phases  can  be  directed.    In  such  a  situation  a  move  directly 
from  Phase  I  to  Phase  V  is  well  within  the  realm  of  possibilities. 

CAS  participants  include  the  National  Command  Authorities  (NCA),  Joint  Chiefs 
of  Staff  (JCS),  supported  command  (usually  the  Unified  Commander  responsible  for 
execution  or  plan  development),  supporting  commands  (commands  who  provide 
augmentation  forces  or  other  support  to  the  supported  command),  military  services, 
USTRANSCOM,  and  the  TOAs.  The  primary  means  of  interface  and  communications 
for  CAS  is  the  Joint  Deployment  System  (JDS)  and  the  World-Wide  Military  Command 
and  Control  System  (WWMCCS).  While  CAS  covers  the  entire  deployment  effort,  only 
those  functions  germane  to  the  sealift  execution  problem  will  be  discussed  here. 

A.  CAS  PHASES  I  AND  II  -  SITUATION  DEVELOPMENT  ANT)  CRISIS 
ASSESSMENT 

CAS  Phases  I  and  II  are  essentially  crisis  identification  and  monitoring  phases.  JCS 
activates  the  CAS  when  it  determines  that  a  given  situation  has  the  potential  to  escalate 
into  a  crisis.  JCS  may  at  this  juncture  direct  all  participants  to  join  a  JDS  on-line  crisis 
teleconference  through  WWMCCS  [Ref.  3: p.  1-2-1]. 

B.  CAS  PHASE  IH  -  COURSE  OF  ACTION  DEVELOPMENT 

Phase  II  terminates  and  Phase  III  commences  with  the  issuance  of  the  Warning 
Order  from  JCS  [Ref.  3:p.  1-2-2].  The  Warning  Order  contains  the  following  elements: 


•  Situation 

•  Specific  forces  to  include  identification  of  supported  and  supporting  commands 

•  Mission 

•  Potential  Courses  of  Action  (COA) 

•  Designation  of  potential  commencement  of  deployment  and  employment  dates 
(C-Day  and  D-Day) 

•  Initial  allocation  of  lift  resources  for  planning 

•  Other  information  required  for  execution  planning 


The  responsibility  of  the  supported  command  during  this  phase  is  to  further  develop 
the  potential  COAs.  This  can  be  accomplished  in  one  of  several  ways.  The  preferred 
method  is  to  utilize  an  OPLAN  already  generated  for  JDS.  This  OPLAN  will  be  a 
product  of  the  deliberate  planning  process  and  will  require  some  revision  to  meet  the 
specific  requirements  of  the  crisis  response.  For  those  situations  where  no  OPLAN  is 
available,  a  COA  can  be  developed  on-line  with  JDS  or  off-line  locally  for  later  input  to 
JDS.  The  latter  method  has  the  disadvantage  of  not  allowing  the  supporting  commands 
to  participate  on-line  in  the  development  process,  possibly  requiring  further  revisions  after 
the  other  participants  are  able  to  review  the  COA. 

Once  development  of  a  particular  COA  is  complete,  USTRANSCOM  is  notified  by 
the  supported  command  that  the  COA  is  available  for  a  deployment  estimate.  The  next 
step  is  to  determine  a  closure  estimate.  A  closure  estimate  is  a  projected  date  of 
completion  for  the  deployment,  expressed  relative  to  C-Day.  With  the  TOAs, 
USTRANSCOM  provides  closure  estimates  for  each  mode  of  transportation.  At  the 
same  time  USTRANSCOM  and  the  TOAs  are  at  work  on  these  estimates,  the  supporting 
command  and  the  services  are  analyzing  the  COA  to  determine  the  feasibility  and 
supportablilty  issues  critical  to  the  operation.  Depending  on  time-constraints,  this  can  be 
an  iterative  process,  requiring  the  supported  command  to  make  changes  to  the  COA  based 
on  responses  from  USTRANSCOM,  supporting  command,  and  services. 

The  end  product  of  the  phase  is  the  Commander's  Estimate  (OPREP-1).  This 
message  is  generated  by  the  supported  command  after  the  deployment  estimates  are 
received  from  USTRANSCOM  [Ref.  3:p.  1-3-9].  The  Commander's  Estimate  is 
forwarded  to  JCS  along  with  a  recommended  COA  for  decision. 


C.  CAS  PHASE  IV  -  COURSE  OF  ACTION  SELECTION 

Phase  IV  essentially  consists  of  a  decision  stage.  At  this  point,  the  National 
Command  Authority  (NCA)  has  the  Commander's  Estimate  and  is  considering  the  COAs 
that  have  been  developed  for  the  crisis.  Meanwhile,  JCS  has  the  option  of  issuing  a 
Planning  Order  to  the  participants.  The  main  purpose  of  this  order  is  to  speed  up 
execution  planning  by  providing  specific  guidance  for  actions  to  be  taken  in  advance  of 
the  NCA  decision.  Depending  on  the  situation,  the  Planning  Order  may  be  the  first 
official  guidance  provided  to  some  of  the  participants  or  it  may  be  an  update  of  previous 
guidance.   The  Planning  Order  will  normally  contain  the  following  elements: 

•  Forces  and  resources  to  be  used  in  planning 

•  Objectives,  tasks,  and  constraints  of  the  operation 

•  Further  planning  guidance  as  appropriate 

•  Deadline  for  operation  order 

The  participants  will  begin  planning  in  accordance  with  the  direction  of  the 
Planning  Order.  [Ref.  2: p.  229] 

D.  CAS  PHASE  V  -  EXECUTION  PLANNING 

This  crucial  phase  begins  with  the  issue  of  the  Alert  Order  from  JCS  indicating  the 
COA  selected  by  the  NCA  and  tentative  or  actual  target  dates  for  the  operation.  Based 
on  the  information  in  the  Alert  Order,  the  supported  command  converts  the  COA  into  the 
operation  order  (OPORD).  The  successful  completion  of  this  phase  is  critically 
dependent  upon  USTRANSCOM  and  JDS.  USTRANSCOM  is  the  central  coordinator 
for  execution  planning  and  JDS  is  the  primary  instrument  of  that  planning  and 
coordination.  The  central  object  of  planning  is  the  first  increment  of  deployment,  relative 
to  the  Earliest  Arrival  Date  (EAD)  and  C-Day  (C0O0).    For  sealift,  the  first  increment 


is  30  days  of  scheduled  lift  from  COOO  -  C029.  For  airlift,  the  first  increment  is  7  days 
of  scheduled  lift  from  COOO  -  C006.  [Ref.  3:pp.  1-9-5  -  1-9-8] 

Initially,  USTRANSCOM  releases  JDS  coordinating  instructions  to  all  participants. 
Included  in  these  instructions  are  target  dates  for  completion  of  updates  to  the  JDS  data 
base.  For  the  supported  command,  these  updates  are  generated  adjusting  the  requirements 
of  the  COA  to  correspond  to  the  Alert  Order.  The  supported  command  is  also  required 
to  validate  and  update  the  data  base  for  the  first  increment.  When  USTRANSCOM 
receives  notification  of  validation  completion,  the  supporting  command  is  notified  to 
begin  sourcing  the  increment.  Sourcing  is  a  procedure  by  which  the  supporting  command 
resolves  actual  units,  origins,  and  other  characteristics  against  the  hypothetical  force 
requirements  contained  in  the  Time-Phased  Force  Deployment  Data  (TPFDD)  file  [Ref. 
2:p.  335].  Accurate  sourcing  is  critical  to  successful  movement.  If  unexpected  or  non- 
standard units  or  unit  equipment  are  to  be  moved,  it  may  unnecessarily  delay  items 
crucial  to  the  success  of  the  operation.  The  supporting  command  is  also  responsible  for 
scheduling  and  manifesting  organic  transportation.  Organic  transportation  is  defined  as 
transportation  resources  assigned  to  a  unit  that  can  provide  lift  capability  for  part  or  all 
of  the  unit's  movement  requirements,  requiring  partial  or  no  support  from  the  TOAs 
[Ref.  4:p.  5-24]. 

USTRANSCOM  will  perform  data  validation  upon  the  data  base  once  it  is  notified 
by  the  supporting  command  that  sourcing  and  updating  is  complete.  Once  this  data 
validation  procedure  is  complete,  the  data  base  is  released  to  the  TOAs  for  scheduling. 
The  TOAs  will  schedule  lift  for  the  first  increment  and  any  preparatory  moves  called  for 
in  the  OPORD.  Entry  of  airlift  schedules  is  expected  within  12-36  hours  from  release 
and  sealift  schedules  within  24-48  hours.  After  the  schedules  are  entered  and 
USTRANSCOM  is  notified,  no  changes  are  allowed  to  the  data  base  unless  coordinated 
through  USTRANSCOM. 

USTRANSCOM  is  also  tasked  with  monitoring  any  preparatory  moves  as  scheduled 
above.  These  moves  are  normally  reflected  as  N-Day  requirements  in  the  data  base, 
where  N  is  the  number  of  days  before  C-Day  [Ref.  3:p.  1-9-10].    For  example,  N002 
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would  be  two  days  prior  to  C-Day.  Once  a  preparatory  move  is  completed,  either  the 
supporting  command  or  the  parent  service  is  tasked  with  updating  the  data  base  to  reflect 
the  new  geographic  location  of  that  unit.  No  further  moves  are  made  until  the  execution 
order  is  given  to  begin  Phase  VI. 

E.  CAS  PHASE  VI  -  EXECUTION 

The  execution  phase  begins  with  the  issue  of  the  execution  order  from  the  NCA  via 
JCS.  When  the  order  is  received,  the  date  and  time  for  execution  is  reviewed  to 
determine  if  any  adjustment  is  required  to  the  first  increment.  If  significant  adjustments 
are  required,  the  TO  As  may  elect  to  recompute  the  entire  schedule,  a  process  known  as 
reflowing  the  increment.  If  only  minor  changes  are  required,  then  the  changes  are  made 
and  execution  begins  as  scheduled  [Ref.  3:p.  1-9-12].  USTRANSCOM  will  then  begin 
transmission  of  Automated  Scheduling  Messages  (ASMs)  to  the  units  or  major  commands 
involved.  The  TOAs  continue  incremental  scheduling,  adding  a  day  or  more  of 
scheduling  information  to  JDS  with  each  iteration.  They  also  maintain  the  actual  status 
of  units  and  lifts  in  JDS  while  USTRANSCOM  assumes  a  monitoring  and  coordination 
role.   The  actions  performed  during  this  phase  continue  until  the  operation  is  complete. 

F.  CAS  TIMING  FACTORS 

As  has  been  stated  before,  the  major  thrust  of  CAS  is  expedient  deployment  of 
forces  in  a  time-critical  crisis.  The  possible  compression  of  phases  and  limited  time  to 
plan  places  a  severe  strain  on  current  sealift  scheduling  resources.  A  period  of  24-48 
hours  to  schedule  sealift  for  a  major  mobilization  is  a  significant  undertaking  for  a 
computerized  scheduling  system,  let  alone  a  manual  one.  Unfortunately,  with  the  dearth 
of  resources  devoted  to  the  execution  scheduling  problem,  the  latter  approach  is  the  one 
most  often  used.  The  following  chapter  will  describe  the  systems  that  are  currently 
available  and  their  shortfalls  with  respect  to  the  execution  scheduling  problem. 


m.  EXISTING  SYSTEMS 

There  are  two  primary  deficiencies  in  existing  systems  that  preclude  acceptable 
performance  in  sealift  execution  scheduling.  The  first  deficiency  is  one  of  purpose. 
Much  of  the  software  that  has  been  developed  to  date  has  been  established  to  validate 
operational  plans.  They  do  well  at  evaluating  feasibility,  but  fall  short  in  terms  of 
efficient  scheduling.  The  Strategic  Sealift  Contingency  Planning  System  (SEACOP)  can 
take  up  to  18  hours  to  evaluate  a  plan.  The  other  problem  is  a  consequence  of  the  size 
of  the  deployment  database  involved  in  executing  a  plan.  In  order  to  manage  the  vast 
amounts  of  data  associated  with  this  process,  the  data  base  management  system  approach 
has  been  embraced.  The  Joint  Deployment  System  (JDS)  and  the  Command  and  Control 
Center  Prototype,  explained  below,  are  both  examples  of  this  approach.  Unfortunately, 
the  computational  overhead  associated  with  a  data  base  system  is  too  severe  both  in 
memory  usage  and  CPU  time  to  be  effective  in  a  scheduling  role. 

A.      JOINT  DEPLOYMENT  SYSTEM 

1.      Background 

The  Joint  Deployment  System  is  defined  by  AFSC-1  [Ref.  2:p.  319]  as: 

Personnel,  procedures,  directives,  communications  systems,  and  electronic  data 
processing  systems  that  directly  support  time-sensitive  planning  and  execution  and 
complement  peacetime  deliberate  planning  by  disseminating  deployment 
information. 

The  electronic  data  processing  system  portion  of  JDS  is  an  extensive  information  storage 

and  retrieval  system  with  a  graphical  display  system  to  allow  geographic  displays  of  the 

deployment  objectives  and  process.   It  is  the  sole  source  of  deployment  information  for 

the  TOAs  and  is  controlled  by  USTRANSCOM.  JDS  does  not  perform  scheduling;  rather 

it  is  the  input  and  output  point  for  the  scheduling  packages  of  the  TOAs.  The  information 

that  JDS  provides  is  the  applicable  portions  of  a  plan's  TPFDD.   These  data  encompass 
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all  of  the  movement  and  cargo  requirements,  prioritization  of  arrivals,  and  other  data  for 
a  given  plan.  [Ref.  2:p.  337] 

2.  Interfaces/Users 

The  TO  As  access  JDS  through  WMMCCS.  In  the  case  of  MSC  however,  its 
JDS  support  comes  through  the  OPNAV  WMMCCS  site  located  at  the  Pentagon.  MSC 
and  the  area  commands,  MSCLANT  and  MSCPAC,  have  on-line  access  to  JDS,  but  they 
are  not  supported  as  JDS  end-users  by  the  JDS  support  organization.  Information  can  be 
retrieved  in  the  form  of  printed  reports  or  on  magnetic  media.  It  can  be  retrieved  in 
pre-specified  formats,  or  specialized  retrievals  can  be  developed  to  extract  required 
information  using  a  retrieval  language  similar  in  syntax  and  format  to  COBOL. 

Returning  processed  schedules  to  JDS  is  not  quite  as  simple.  The  WMMCCS 
Intercomputer  Network  (WIN)  sites  at  MSC  and  the  area  commands  are  secure  areas  with 
tightly  controlled  access,  due  to  the  nature  of  the  information  available.  One  of  the 
restrictions  placed  upon  such  sites  is  that  magnetic  media  may  only  be  brought  into  the 
site  with  absolutely  no  information  contained  upon  it.  This  precludes  any  automated 
input  of  scheduling  information  developed  outside  of  the  WIN  site.  At  present  no  means 
exist  to  develop  that  information  within  the  site.  Therefore,  any  scheduling  information 
developed  by  an  MSC  Area  Command  must  be  entered  into  JDS  manually  by  WIN 
personnel. 

3.  Limitations 

Interface  with  JDS  is  necessary  for  any  sealift  scheduling  system,  be  that 
interface  direct  or  indirect.  Using  JDS's  retrieval  language  to  do  the  scheduling  is  not  a 
viable  option,  though  properly  structured  and  supported  retrievals  could  be  of  immense 
help  in  reducing  the  workload  for  a  scheduling  system.  Proper  support  would  include 
assistance  in  developing  those  retrievals  from  the  JDS  support  organization  at 
USTRANSCOM  and  in  rewriting  those  retrievals  when  changes  are  made  to  the  JDS 
database  structure. 
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The  performance  of  any  scheduling  system  will  also  be  degraded  by  any 
manual  transfer  of  information.  A  system  which  develops  a  schedule  in  12  hours,  but 
takes  another  12  hours  for  the  schedule  data  to  be  entered  manually  is  not  responsive  to 
a  crisis.  Some  means  of  on-line  or  automated  communication  with  JDS  must  be 
established.  This  can  be  accomplished  by  incorporating  the  system  in  the  WIN  site  or  by 
modifying  the  entry  restrictions  to  allow  magnetic  media  containing  the  schedule  to  enter 
the  site.  One  possible  solution  would  be  to  use  some  type  of  encoding  which  would  allow 
a  WIN  operator  to  determine  if  the  information  has  been  corrupted  or  tampered  with. 
The  security  of  the  site  should  not  be  compromised,  but  some  means  must  be  found  of 
transferring  the  schedule  electronically  at  the  area  command  level. 

B.      STRATEGIC  SEALIFT  CONTINGENCY  PLANNING  SYSTEM 

1.      Background 

SEACOP  is  a  system  initially  developed  in  1972  as  a  transportation  planning 
model  sponsored  by  the  Strategic  Sealift  Division  of  CNO  (OP-42)  [Ref.  5:pp.  iv,  1-3]. 
It  is  operated  by  MSC  and  is  used  to  generate  schedules  based  on  a  plan,  exercise,  or 
study.  It  is  in  its  fourth  development  iteration  and  resides  on  a  WMMCCS  Honeywell 
6000  at  the  Washington  Navy  Yard.  It  is  essentially  a  single  plan  gross  scheduler  which 
uses  a  heuristic  process  to  schedule  plan  lift  requirements  against  lift  assets,  port 
constraints,  and  time  requirements.  It  produces  several  feasible  schedules  from  which  a 
"best"  schedule  may  be  selected.  It  is  a  deliberate  planning  tool  that  is  often  used  for 
actual  scheduling  given  the  fact  that  nothing  else  exists  for  that  purpose.  It  can  take  up 
to  18  hours  to  run,  depending  on  the  size  of  the  plan.  It  is  constrained  to  a  single  reel 
of  tape  for  input,  which  requires  extraction  of  the  sealift  requirements  from  the  TPFDD 
for  a  large  plan  [Ref.  5:p.  1-19]. 
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2.  Interfaces/Users 

SEACOP  receives  the  TPFDD  and  movement  table  by  tape  downloaded  from 
JDS  and  MTMC  through  the  MSC  WIN  site.  Ship  information  and  allocations  are 
obtained  from  the  Joint  Strategic  Capabilities  Plan  (JSCP)  Annex  J  and,  where  necessary, 
on  tape  from  the  Navy  Operational  Intelligence  Center.  It  uses  several  internal  files 
including  a  port  characteristics  file  and  a  type  unit  characteristics  (TUCHA)  file 
containing  detailed  cargo  data  and  quantities  for  standard  military  units  [Ref.  5: pp.  1-13  - 
1-14].  The  output  consists  of  selected  reports  and  an  MSC  movement  records  file  which 
is  transferred  via  WIN  to  USTRANSCOM/JDS.  Additional  information  extracted  from 
the  schedule  is  made  available  to  MTMC  and  the  MSC  area  commands  through  the  WIN 
site. 

MSC  is  the  sole  user  of  SEACOP.  Planners  who  wish  to  validate  a  plan  must 
submit  the  tape  to  MSC  and  request  MSC  conduct  the  SEACOP  analysis.  MSC  area 
commands  have  no  capability  to  use  SEACOP,  even  though  the  movement  requirements 
that  they  extract  from  JDS  are  generated  by  SEACOP. 

3.  Limitations 

SEACOP  is  a  deliberate  planning  tool  inappropriate  for  execution  scheduling. 
It  has  no  capability  to  reanalyze  or  readjust  a  schedule.  Its  heuristic  processes  are  slow 
and  do  not  necessarily  produce  an  optimal  schedule.  It  has  been  modified  extensively  and 
lacks  potential  for  any  improvement.  Unfortunately,  until  something  better  can  be 
developed,  it  is  the  only  sealift  scheduling  tool  available.  This  is  also  unfortunate  for  the 
area  commands  in  that  they  still  have  no  definitive  software  scheduling  aid,  and  in  a 
deployment,  exercise  or  actual,  most  of  the  scheduling  will  fall  upon  them. 
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C.      SEASTRAT/SAIL 

1.  Background 

The  Sealift  Strategic  Analysis  System  (SEASTRAT)  is  the  new  deliberate 
planning  tool  for  sealift  scheduling  under  development  by  the  Navy  Regional  Data 
Automation  Center  (NARDAC)  in  Washington,  D.C.  [Ref.  6:pp.  xi,  3].  SAIL,  the 
Scheduling  Algorithm  For  Improving  Lift  is  being  developed  as  a  subsystem  by  the 
Computing  and  Telecommunications  Division  at  the  Oak  Ridge  National  Laboratory 
(ORNL).  It  is  being  implemented  on  a  new  IBM  3090  mainframe  computer  at  MSC  by 
NARDAC  and  ORNL.  SAIL  uses  a  combination  of  linear  optimization  and  heuristic 
techniques  to  develop  schedules  for  planning  and  validation  purposes.  It  is  written  in 
FORTRAN  77  and  interfaces  to  SEASTRAT  and  the  required  files  through  the  mainframe 
database  system,  FOCUS.  It  is  still  in  development  and  testing,  and  as  its  developers 
indicate,  is  subject  to  "...changes  in  the  overall  planning  process  within  the  deployment 
community."  [Ref.  6:p.  5]  SAIL  uses  specific  aggregation  techniques  to  reduce  the 
number  of  cargos  for  scheduling  by  combining  cargos  into  a  "channel".  This  "channel" 
consists  of  a  group  of  cargos  with  similar  characteristics  and  delivery  constraints.  This 
allows  the  lift  process  to  be  modelled  as  a  continuous  flow,  a  necessary  condition  for  a 
linear  programming  formulation.  SAIL  also  uses  simulation  routines  to  derive  port 
queueing  and  loading  times  to  give  a  more  realistic  appraisal  of  plan  feasibility. 

2.  Interfaces/Users 

The  inputs  and  outputs  of  this  system  are  not  unlike  those  of  SEACOP.  One 
difference  is  the  use  of  FOCUS  by  SEASTRAT  to  manage  the  information  files  used  by 
SAIL.  Although  this  provides  a  means  of  easing  the  data  management  effort,  it  has  a 
negative  effect  upon  system  execution  time  due  to  the  computational  overhead  inherent 
in  using  FOCUS.  The  output  side  is  similar  in  that  it  has  to  be  able  to  communicate  with 
JDS. 
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3.      Limitations 

The  developers  of  SAIL  stipulate  from  the  beginning  that  it  is  a  deliberate 
planning  tool  not  intended  for  execution  scheduling.  Even  with  its  aggregation 
techniques,  the  structure  of  an  actual  execution  problem  may  still  be  difficult  for  a  linear 
programming  transportation  formulation.  One  consequence  of  the  channelization 
approach  is  that  once  cargoes  are  aggregated  into  a  channel  they  lose  their  individual 
identities.  This  is  not  acceptable  for  an  execution  scheduling  system  which  must  allow 
for  retrieval  of  a  cargo's  status  at  any  given  time  in  the  deployment  process.  A  more 
discrete  approach  may  preclude  a  linear  programming  approach.  SEASTRAT's  use  of 
FOCUS  as  the  database  interface  causes  severe  difficulties  for  the  system  in  terms  of 
package  execution  time.  However,  the  system's  purpose  for  existence  is  plan  validation. 
It  appears  to  be  a  reasonable  and  intelligent  attempt  to  address  the  lift  scheduling 
problem.  Since  it  is  a  deliberate  planning  tool,  it  is  not  designed  to  be  able  to  address  the 
unique  requirements  of  an  execution  scheduling  system.  This  does  not  exclude  the 
possibility  that  an  execution  scheduling  system  might  be  able  to  draw  upon  those  elements 
in  SEASTRAT/SAIL  that  would  be  appropriate  for  the  execution  scheduling  problem. 

D.      COMMAND  AND  CONTROL  CENTER  PROTOTYPE 

1.      Background 

The  Command  and  Control  Center  (CCC)  Prototype  is  a  PC  based  information 
system  implemented  on  a  TEMPEST-certified,  secure  Zenith  AT-Compatible  with  two 
removable  ten  megabyte  hard  drives.  It  is  a  combination  of  AUTOCAD  for  graphical 
displays,  Paradox  for  the  database,  Software  Carousel  to  allow  for  swapping  between  the 
two,  and  a  driver  program  written  in  C.  The  database  retrieval  routines  are  written  in  a 
Paradox-specific  retrieval  language  and  compiled  so  as  to  be  inaccessible  to  the  users. 
It  was  developed  under  MSC  contract  and  was  put  into  operational  testing  at  MSC 
Headquarters  and  the  area  commands  in  the  fall  of  1988.  At  that  time,  the  system  was 
only  capable  of  using  movement  reports  to  track  the  location  of  ships.   The  users  at  the 
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area  commands  were  under  the  impression  that  the  system  in  a  later  iteration  would  be 
capable  of  serving  in  a  scheduling  role. 

2.  Interfaces/Users 

At  the  time  of  its  operational  test,  the  CCC  prototype  had  no  means  of 
automated  input.  Entering  movement  report  data  was  completely  dependent  upon 
keyboard  entry.  It  had  no  capability  to  extract  information  on-line,  though  it  was  thought 
that  database  files  might  be  transferred  from  the  CCC  prototype  at  MSC  headquarters  to 
the  area  commands  via  the  secure  data  transfer  mode  of  the  STU-III  Secure  Telephone 
System.  This  would  still  mean  that  the  information  would  have  to  be  entered  manually 
at  some  point,  be  it  at  headquarters  or  the  area  commands. 

There  were  only  two  means  available  of  retrieving  information  from  the 
prototype.  The  first  was  through  printed  reports  and  the  other  would  be  through  the 
displays  generated  by  AUTOCAD.  Unfortunately,  the  secure  Zeniths  are  equipped  with 
only  a  Color  Graphics  Adapter  and  Display.  The  information  displayed  by  AUTOCAD 
at  that  resolution  was  so  cluttered  as  to  be  of  limited  value. 

3.  Limitations 

The  CCC  prototype  is  an  example  of  an  ill-conceived  and  poorly  executed 
software  procurement.  It  performs  only  nominally  in  its  information  retrieval  role  and 
is  so  constrained  by  all  aspects  of  the  Zeniths  as  to  restrict  the  potential  for  enhancing  or 
expanding  the  system.  In  terms  of  disk  space,  it  uses  most  of  the  storage  available  on 
each  of  the  ten  megabyte  drives.  With  both  AUTOCAD,  Paradox,  and  Software 
Carousel  it  consumes  virtually  all  of  the  Zenith's  main  memory  and  a  two  megabyte 
extended  memory  card,  leaving  little  room  to  operate  on  new  data.  The  loading  and 
execution  of  the  package  is  painfully  slow.  The  system  requires  that  AUTOCAD  be 
loaded,  executed  in  full,  and  swapped  out  before  Paradox  can  be  loaded  and  run.  This 
entire  process  takes  about  ten  minutes  before  any  data  entry  or  retrieval  can  be 
performed.  Initial  indications  were  that  the  removable  drives,  known  for  their  slow 
throughput,  were  the  reason  for  the  slowness  of  this  process.    An  interleave  adjustment 
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was  performed,  increasing  the  access  speed  of  the  disks  by  50%  according  to  recognized 
benchmarks.  When  the  system  was  loaded  from  those  disks,  there  was  no  appreciable 
decrease  in  the  loading  time,  indicating  that  the  process  was  CPU  intensive,  not  disk 
intensive. 

The  contractor  has  addressed  some  of  these  concerns  and  stipulates  that  most 
of  the  problems  will  be  solved  if  the  system  is  implemented  on  an  80386  based  PC. 
Unfortunately,  at  the  time  of  this  writing  there  are  no  TEMPEST-certified  80386 
machines  available,  so  use  of  a  non-TEMPEST  machine,  while  still  being  able  to 
minimize  the  TEMPEST  hazard,  is  being  investigated.  Such  a  system  would  probably 
make  the  information  retrieval  and  display  less  painful,  but  is  still  not  likely  to  allow  for 
the  expansion  of  the  package  in  terms  of  scheduling.  And  the  communications/data 
transfer  aspects  remain  unaddressed. 

E.      OTHER  SYSTEMS 

Many  other  avenues  have  been  explored  on  an  in-house  level  to  assist  in  sealift 
scheduling.  One  example  is  a  program  of  approximately  2500  lines  of  BASIC  code  to 
sort  the  movement  data  downloaded  from  the  WIN.  This  program  sorts  the  data  by 
POE,  POD,  and  ALD,  extracts  the  valid  unscheduled  cargo,  and  provides  a  gross 
assessment  of  how  many  of  each  possible  type  of  lift  asset  would  be  necessary  to  move 
the  unscheduled  requirements.  Unfortunately  this  program  is  strictly  dependent  upon  the 
format  of  the  retrievals  from  JDS.  Given  the  fact  that  the  area  commands  are  not 
supported  JDS  users,  they  have  no  control  over  those  retrievals.  And  those  retrievals 
could  easily  be  rendered  useless  by  changes  to  the  JDS  database.  Any  system  to  perform 
sealift  execution  scheduling  must  be  isolated  from  such  changes. 
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IV.  SYSTEM  REQUIREMENTS 

A.      LEVEL  OF  SYSTEM  OPERATION 

One  of  the  critical  factors  in  an  execution  scheduling  system  must  be  a  clear 
specification  of  the  level  at  which  each  of  the  potential  users/user  organizations  may 
exercise  control  over  its  operation.  Those  users,  whose  need  for  the  system  is  strictly 
informational  do  not  need  the  same  access  to  the  system  that  a  person  with  scheduling 
authority  needs.  Therefore,  a  distributed  approach  to  sealift  scheduling  is  in  order  for  the 
execution  problem. 

1.  USTRANSCOM 

USTRANSCOM  would,  at  most,  need  informational  access  to  the  system.  If 
the  system  were  properly  configured  to  interface  with  JDS,  USTRANSCOM  would  likely 
satisfy  its  informational  requirements  from  JDS  and  not  even  bother  with  access  to  the 
system. 

2.  MSC  Headquarters 

Owing  to  the  fact  that  execution  scheduling  in  the  past  has  been  dependent 
upon  the  deliberate  planning  tools  available  at  MSC  Headquarters,  MSC  has  been  heavily 
involved  in  the  initial  stages  of  the  actual  scheduling  process.  Their  ability  to  participate 
beyond  the  first  increment  is  limited  by  SEACOP's  restriction  to  a  single  schedule.  But 
under  ideal  circumstances  MSC  should  occupy  a  role  similar  to  USTRANSCOM.  It 
should  monitor  the  scheduling  process,  allowing  the  personnel  at  the  area  commands  with 
the  first-hand  knowledge  critical  to  effective  scheduling  to  perform  the  actual  scheduling 
tasks.  This  monitoring  could  possibly  be  accomplished  through  JDS  as  well.  If  a 
determination  is  made  that  MSC  Headquarters  should  have  a  participatory  role,  that 
participation  should  be  limited  to  the  first  increment. 
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3.     MSC  Area  Commands 

The  two  MSC  area  commands  that  will  be  crucial  to  mobilization  planning  and 
execution  are  MSCLANT  and  MSCPAC.  Responsibility  for  ensuring  the  timely 
scheduling  of  lift  rests  squarely  within  those  two  commands.  They  are,  in  fact,  the 
operational  commands  of  MSC.  The  local  knowledge  of  facilities,  characteristics,  and 
quirks  of  the  their  transportation  environments  is  critical  to  effective  scheduling.  Yet, 
these  areas  have  been  the  most  ignored  in  terms  of  automated  scheduling  support.  Any 
given  OPLAN  can  require  the  scheduling  and  coordination  of  thousands  of  items,  all  with 
several  specific  time  and  loading  constraints.  This  is  currently  accomplished  with  pencil 
and  paper.  MSCLANT  and  MSCPAC  are  where  the  emphasis  on  sealift  execution 
scheduling  should  be  placed.  Any  tools  developed  for  their  use  should  be  closely 
coordinated  with  their  scheduling  personnel,  not  just  their  procurement  or  ADP  personnel. 
This  was  not  what  was  done  with  the  CCC  Prototype  and  the  result  will  likely  be  the 
death  of  that  package.  It  is  a  well  known  fact  in  software  development  that  proper 
requirements  definition  will  make  or  break  a  package.  This  package  should  be  designed 
specifically  for  the  use  of  the  area  commands  in  the  context  of  their  facilities  and 
requirements,  preferably  through  contact  with  personnel  at  the  area  commands. 

B.      OPTEVIALITY/PERFORMANCE  CRITERIA 

The  most  significant  parameter  in  the  whole  arena  of  sealift  execution  is  time.  In 
a  crisis  situation,  the  search  for  the  optimal  schedule  becomes  secondary  to  the  availability 
of  scheduling  time.  Such  a  search  can  involve  evaluation  of  several  deployment  and 
schedule  options.  Therefore,  the  developer  must  define  speed  of  package  execution  as 
the  objective  function,  with  schedule  feasibility/optimality  as  a  constraint.  This  is  not  to 
suggest  that  optimality  be  ignored.  In  an  era  of  scarce  sealift  resources,  inefficient  use 
of  assets  could  be  deadly.  But  instead  of  an  exhaustive  search  for  the  optimal  schedule, 
the  emphasis  should  be  placed  on  developing  a  "good"  schedule  that  observes  the 
feasibility  constraints  placed  upon  it.   This  may,  in  fact,  require  more  human  interaction 
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or  heuristics  to  identify  a  "good"  schedule  than  would  be  normally  present  in  a  pure 
optimization/scheduling  package,  but  this  is  not  a  typical  scheduling  problem.  SEACOP 
is  widely  recognized  as  a  bad  approach  to  the  problem,  consuming  large  computing 
resources  and  time  without  rendering  any  flexibility  to  evaluate  alternative  lift  options. 

C.      SOFTWARE  DEVELOPMENT  CONSIDERATIONS 

As  documented  previously,  attempts  to  manage  the  execution  scheduling  problem 
with  existing  systems  or  database  management  systems  (DBMS)  have  met  with  little  or 
no  success.  This  is  because  the  execution  scheduling  problem  is  totally  different  from  the 
problems  that  the  other  systems  were  developed  to  handle.  Execution  scheduling  is  at  its 
core  a  complex  optimization  problem  and  only  an  effort  by  optimization  professionals  will 
yield  a  package  capable  of  meeting  the  challenge. 

An  execution  scheduler  need  not  exist  external  to  a  deliberate  planning  package. 
If  all  of  the  interfaces  and  information  required  for  the  execution  scheduling  package  are 
contained  within  the  deliberate  planning  package,  then  the  scheduler  could  exist  as  an 
independent  module  included  within.  Unfortunately,  even  SEASTRAT  does  not  meet  this 
requirement.  The  IBM  3090  mainframe  on  which  it  is  being  implemented  is  not 
accessible  to  the  area  commands,  violating  a  major  requirement  for  an  effective  system. 
Therefore,  either  some  means  of  access  to  the  3090  for  the  area  commands  will  need  to 
be  developed  or  the  execution  scheduling  package  will  have  to  be  developed 
independently. 

Another  approach  to  avoid  in  scheduler  development  is  the  DBMS  approach.  This 
approach  can  be  manifested  either  by  developing  the  scheduler  in  a  DBMS  retrieval 
language  or  by  tying  it  to  a  DBMS  for  its  input  and  output.  The  problem  with  the  first 
method  is  that  a  DBMS  retrieval  language  is  not  suited  for  the  significantly  complex  and 
time-critical  computations  inherent  in  an  optimization  problem.  It  is  akin  to  trying  to 
write  a  supercomputer  operating  system  in  BASIC.  It  can  be  done,  but  it  would  make 
little  sense  to  do  so.     The  problem  with  the  second  method  is  time.     Input/output 
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processes  are  slow  enough  without  compounding  the  situation  with  calls  to  a  DBMS. 
However,  it  is  recognized  that  the  amount  of  data  used  by  a  scheduler  would  be  extremely 
large  and  difficult  to  compile  and  maintain  without  a  DBMS.  The  key  here  is  to  structure 
the  scheduler  to  take  input  from  a  flat  or  text  file  format  containing  only  that  information 
required  for  scheduling.  This  flat  file  format  could  be  produced  by  the  DBMS  following 
an  update  so  that  it  would  be  available  to  the  scheduler.  This  way  the  scheduler  could 
input  the  information  much  faster  than  it  would  by  making  calls  to  the  DBMS  for  each 
item  required. 

Another  popular  trend  in  software  development  is  to  utilize  off-the-shelf  software 
to  drive  down  procurement  costs,  especially  for  Personal  Computer  (PC)  software.  This 
may  be  appropriate  for  a  DBMS  or  word  processor,  but  it  is  entirely  unsuitable  for 
scheduling  purposes.  The  CCC  Prototype  is  an  excellent  example  of  that  fact.  Even 
most  of  the  popular  optimization  packages  available  today  would  be  unable  to  deal  with 
the  requirements  of  this  system  without  substantial  modification.  It  should  also  be 
mentioned  that  while  keeping  a  package  small  and  portable  enough  to  run  on  a  PC  is  an 
admirable  goal,  the  sheer  volume  of  information,  mass  storage,  memory,  and  speed 
demanded  of  a  such  system  will  require  mainframe  computing  power. 

D.      USER  INTERFACE 

The  user  interface  is  a  critical  area  for  two  reasons.  One  reason  is  that  the  time  it 
takes  the  users  to  operate  the  system  can  be  pivotal  in  terms  of  quickly  executing  lift 
options.  If  a  reflow  of  a  COA  is  required  or  the  next  schedule  increment  is  required,  the 
time  required  to  use  the  scheduler  can  slow  up  the  process  significantly,  especially  if  the 
user  is  at  a  remote  site  and  the  communications  link  is  operating  below  9600  baud.  The 
other  reason  lies  in  the  fact  that  the  scheduler  will  be  ineffective  as  a  "black-box" 
optimization  package.  It  is  the  nature  of  military  operations  that  changes  and  exceptions 
are  often  made.  Sealift  is  not  exempt  from  such  changes.  The  Naval  Control  of  Shipping 
Organization  (NCSORG)  is  a  prime  source  of  possible  changes  [Ref.  7].  It  will  have  the 
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authority,  when  established,  to  control  ports,  schedules,  and  convoys,  all  of  which  will 
have  a  significant  effect  on  scheduling  procedures.  Some  override  capability  must  be 
designed  into  the  system.  Manual  verification  and  approval  procedures  must  be 
incorporated  into  the  scheduler.  This  might  appear  difficult  from  the  standpoint  of  a 
optimization  package.  However,  Brown  et  al.  [Ref.  8]  developed  such  a  system  for 
Mobil  Oil  that  has  increased  productivity  and  saved  money.  The  task  here  is  not 
insurmountable. 

E.       EXTERNAL  INTERFACES 

Again,  speed  and  time  are  the  critical  factors.  The  scheduler  must  be  in  such  a 
position  as  to  effect  a  rapid  exchange  of  information  with  JDS  for  both  the  initial  and 
subsequent  lift  increments.  Too  many  things  depend  upon  that  exchange.  The  entire  JDC 
derives  its  execution  schedules  and  plans  from  JDS.  Manual  entry  of  schedules  through 
a  WIN  site  following  scheduling  is  not  acceptable.  The  scheduler  requires  a  direct 
interface  with  JDS,  preferably  at  a  speed  of  9600  baud  or  greater.  Even  at  that  speed, 
a  large  schedule  could  take  up  to  an  hour  to  upload.  One  place  where  the  transfer  rate 
could  be  improved  is  the  regional  area.  The  CONUS  MSC  and  MTMC  Area  Commands 
are  located  in  close  proximity  to  each  other.  Given  the  close  nature  of  coordination 
required  between  MTMC  and  MSC  locally,  some  sort  of  high  speed,  secure  data  link  or 
even  sharing  of  computing  resources  could  significantly  enhance  that  coordination.  For 
example,  if  it  were  determined  that  MSC's  requirement  for  a  mainframe  computer  in  the 
area  was  not  sufficiently  justified,  perhaps  a  mainframe  computer  for  both  MSC  and 
MTMC  together  would  be  more  easily  supported,  especially  by  USTRANSCOM. 

In  terms  of  information  flow,  some  work  has  been  done  previously  to  study 
requirements.  The  U.S.  Department  of  Transportation  prepared  a  report  for  JCS  in  1986 
to  determine  possible  interfaces  for  MTMC  and  MSC  [Ref.  9].  The  report  is  reasonably 
detailed  in  discussing  JDC  and  MTMC  systems,  but  unfortunately  the  preparers  of  the 
report  were  led  to  believe  that  SEASTRAT  would  be  MSC's  execution  scheduling  system. 
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As  of  this  writing,  SEASTRAT  is  only  a  deliberate  planning  tool  with  no  execution 
scheduler  programmed  in  the  immediate  future.  Still,  the  report  can  provide  a  starting 
point  for  establishing  a  more  effective  interface  in  the  locality. 

Two  other  areas  of  interface  to  be  addressed  are  the  Maritime  Administration 
(MarAd)  and  NCSORG.  Mar  Ad  is  responsible  for  supporting  sealift  through  the  Ready 
Reserve  Fleet  (RRF),  National  Defense  Reserve  Fleet  (NDRF),  the  Voluntary  Tanker 
Program,  and  Sealift  Readiness  Program.  In  its  wartime  capacity  as  the  National 
Shipping  Authority  (NSA),  MarAd  is  responsible  for  the  requisitioning  of  U.S.  flag 
merchants  to  provide  additional  lift  in  time  of  war  [Ref.  10].  In  time  of  mobilization, 
MarAd  would  be  the  primary  source  of  lift  assets  for  the  initial  surge.  The  only 
automated  interface  between  MSC  and  MarAd  is  a  secure  teletype  link  referenced  in  the 
Department  of  Defense  and  Department  of  Commerce  memorandum  of  agreement  that 
addresses  shipping  support  of  military  operations  [Ref.  1 1  :p.  17].  This  is  presumably 
where  MarAd  will  identify  assets  to  be  made  available  for  lift  and  MSC  will  identify 
requirements.  Such  a  link  would  be  probably  sufficient  for  those  purposes,  but,  if 
MarAd,  in  its  wartime  capacity  as  the  NSA,  had  a  greater  requirement  for  information, 
that  link  would  have  to  be  reevaluated. 

The  NCSORG  question  is  somewhat  more  difficult.  The  easiest  and  most  desirable 
solution  would  be  to  maintain  scheduling  authority  with  MSC  and  have  the  NCSORG 
direct  schedule  changes  as  necessary.  Some  provision  would  have  to  be  made  to  allow 
informational  access  to  either  the  scheduler  or  JDS  for  the  NCSORG.  The  difficulty  lies 
in  determining  at  which  point  in  the  scheduling  process  NCSORG  would  exercise  its 
scheduling  prerogative.  While  this  would  probably  not  come  into  question  for  a  non- 
wartime  mobilization  or  in  the  initial  stages  of  the  deployment,  it  is  a  factor  which  could 
have  a  significant  effect  upon  scheduling  and  should  be  given  due  consideration  during 
development. 
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V.  ALGORITHMIC  CONSIDERATIONS 

The  selection  of  a  scheduling  algorithm  for  an  execution  scheduling  system  impacts 
all  aspects  of  system  structure.  This  is  a  topic  which  requires  much  more  research  before 
the  design  of  such  a  system  can  be  implemented.  While  it  is  beyond  the  scope  of  this 
thesis  to  actually  develop  the  algorithm  required,  an  examination  of  the  potential  areas  for 
algorithm  selection  and  related  impacts  is  in  order. 

A.      MATHEMATICAL  PROGRAMMING 

The  first  area  of  consideration  is  a  mathematical  programming  approach  to  the 
scheduling  problem.  This  consists  of  linear  and  integer  programming  techniques.  This 
has  been  the  approach  most  frequently  used  in  the  past  for  some  of  the  deliberate  planning 
tools  available  today.  Because  a  linear  programming  problem  formulation  requires  a 
continuous  vice  discrete  flow  structure,  development  to  date  has  centered  around  using 
channelization  as  a  method  of  aggregating  cargo  requirements  to  reduce  the  problem  size 
and  meet  the  continuous  flow  assumption.  Channelization  gives  the  formulation  a 
structure  similar  to  a  pipeline  flow  problem.  For  example,  under  channelization,  a 
10,000  MTon  cargo  moving  from  POE  to  POD  in  10  days  would  not  be  modelled  as 
such.  It  would  be  modelled  as  1000  MTons  flowing  per  day  over  10  days.  This  structure 
was  the  one  for  a  deliberate  planning  package  developed  for  USTRANSCOM  called 
SCOPE-GT  [Ref.  12:p.  21].  It  is  also  the  approach  used  in  SAIL  with  some  modification 
[Ref.  6:p.  19]. 

There  are  some  problems  with  this  approach,  especially  for  execution  scheduling. 
The  most  significant  deficiency  is  one  of  cargo  tracking  and  identification.  If  cargoes  are 
aggregated  into  a  channel  as  a  continuous  flow,  it  becomes  impossible  within  the  structure 
of  the  linear  program  and  solution  to  identify  individual  cargoes  and  ships.     SAIL 
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improves  upon  this  somewhat  by  aggregating  cargoes  into  a  channel  by  unit  loads  and 
trying  to  schedule  a  channel  to  a  single  ship.  However,  there  are  no  guarantees  that  this 
in  fact  will  be  the  result.  [Ref.  6: p.  29]  The  consequence  of  not  aggregating  cargoes 
increases  the  size  of  the  linear  program,  rendering  it  potentially  insoluble.  Yet,  the 
ability  to  track  the  movement  of  cargoes  in  a  discrete  fashion  is  a  necessary  requirement 
for  an  execution  scheduling  system.  Two  previous  Naval  Postgraduate  School  thesis 
students,  Collier  [Ref.  12]  and  Lally  [Ref.  13],  examined  this  deficiency  in  the  context 
of  deliberate  planning  systems  and  offered  integer  programming  and  variable  reduction 
techniques  in  linear  programming  as  potential  means  for  structuring  deliberate  planning 
problems.  Integer  programming  formulations  meet  the  requirements  for  a  discrete 
solution,  but  are  typically  more  intensive  computationally.  Variable  reduction  techniques 
are  used  to  reduce  the  size  of  a  linear  programming  formulation.  With  the  channelization 
approach  as  implemented  in  SAIL,  these  techniques  all  appear  to  be  effective  for  lift 
scheduling  in  the  deliberate  planning  process.  Unfortunately,  they  do  not  appear  to  be 
the  appropriate  strategy  for  execution  scheduling. 

Another  factor  which  weighs  against  the  use  of  these  methods  in  execution 
scheduling  is  the  dynamic  nature  of  execution  scheduling.  A  linear  program  or  an  integer 
program  cannot  be  easily  structured  to  handle  the  increasing  time  window  of  incremental 
scheduling.  These  mathematical  programming  techniques,  by  structure,  require  a 
complete  problem  for  solution.  If  all  of  the  lift  assets,  cargoes,  times,  and  other  critical 
constraints  are  known  in  advance  for  the  entire  execution,  then  such  a  formulation  might 
be  attractive.  Unfortunately,  execution  scheduling  is  done  in  a  dynamic  context  with  the 
scheduling  horizon  increasing  incrementally.  For  example,  a  linear  program  is  used  to 
develop  a  schedule  for  days  C000-C029.  The  increment  is  increased  to  extend  through 
day  C031.  The  linear  program  is  then  used  to  recompute  the  schedule.  Because  the 
linear  program  solves  two  different,  complete  problems,  the  first  schedule  will  likely  have 
little  similarity  to  the  second.  This  can  be  a  problem  if  a  number  of  cargoes  are  already 
waiting  to  load  or  are  in  transit  and  the  second  schedule  mandates  a  move  between  ships. 
The  method  frequently  used  to  alleviate  this  problem  is  to  develop  a  penalty  for  removing 


25 


cargoes  that  have  already  been  loaded.     Unfortunately,  such  methods  unacceptably 
increase  the  computational  size  of  an  already  large  problem. 

However,  total  exclusion  of  mathematical  programming  techniques  in  addressing 
execution  scheduling  is  not  necessarily  desired.  Such  techniques  may  be  appropriate  for 
use  in  a  subproblem  within  the  scheduler.  But,  a  pure  mathematical  programming 
solution  for  the  entire  scheduling  problem  will  not  be  a  viable  approach  in  terms  of 
structure  or  computation  time. 

B.      HEURISTIC  ALGORITHMS 

Given  the  size  of  the  execution  scheduling  problem,  a  heuristic  approach  appears 
to  hold  the  most  promise.  Such  approaches  are  characterized  by  algorithms  that  apply 
intelligent  criteria  to  determine  a  solution  to  a  particular  problem  from  a  large  number  of 
possible  solutions.  The  solution  may  be  approximate,  or  in  the  case  of  optimization 
problems,  sub-optimal.  Some  examples  of  heuristic  algorithms  are  Newton's  method  for 
numerically  approximating  the  value  of  an  integral  or  Dijkstra's  algorithm  for  determining 
the  shortest  path  through  a  network  of  nodes.  Depending  on  the  criteria,  a  heuristic 
algorithm  can  produce  a  solution  very  quickly  or  quite  slowly.  SEACOP's  solution 
algorithm  is  an  example  of  a  heuristic  algorithm  that  performs  its  task  quite  slowly.  It 
develops  schedules  using  a  cost/benefit  analysis  heuristic  that  is  based  on  aggregating  all 
of  the  problem  constraints  into  a  penalty  cost  form.  Wasted  space  on  a  ship  is  an 
example  of  a  constraint  for  which  a  penalty  is  assigned.  After  a  schedule  is  developed, 
it  is  then  examined  for  "goodness",  and  bad  cargo  assignments  are  unassigned  according 
to  the  worst  cost/benefit  values.  Those  cargoes  must  then  be  rescheduled.  This  process 
is  significantly  slow  and  inefficient  in  structure.  [Ref.  5: pp.  2-80  -  2-85] 

However,  not  all  heuristic  approaches  are  as  bad  as  SEACOP's.  In  fact,  one 
solution  methodology  appears  promising.  Within  the  last  several  years,  more  attention 
has  been  given  to  a  class  of  problems  known  as  Vehicle  Routing  with  Time  Windows 
[Ref.  14].    These  essentially  involve  a  network  of  origins,  destinations,  and,  possibly, 


intermediate  stops  for  which  vehicles  must  be  assigned.  For  each  arc  in  the  network,  a 
cost  and  time  to  travel  are  specified.  For  each  node  (stop),  a  time  window  giving  the 
earliest  arrival  date  and  the  latest  arrival  date  is  specified,  a  constraint  structure  quite 
similar  to  the  execution  scheduling  problem.  These  problems,  if  small  or  moderate  in 
size,  are  amenable  to  solution  through  mathematical  programming  techniques.  But  for 
the  large  problems,  the  methodology  centers  around  a  heuristic  approach  to  determine  a 
feasible  routing  solution.  This  solution  might  not  be  the  optimal  solution,  but  given  the 
size  of  the  problem  and  the  difficulty  involved  in  computing  the  optimal  solution,  a 
feasible  schedule  that  is  "good"  is  acceptable.  One  such  heuristic  is  a  generalized 
permanent  labeling  algorithm  as  applied  to  the  time  windows  structure  [Ref.  15].  This 
heuristic  is  essentially  a  shortest  path  algorithm  modified  to  consider  time  windows. 
Another  is  the  Advanced  Dial-A-Ride  with  Time  Windows  heuristic  algorithm  [Ref.  16] 
which  deals  with  pickup,  delivery,  and  quality  constraints  in  scheduling  multiple  vehicles. 
Requests  for  pickup  are  made  dynamically,  though  well  in  advance  of  the  pickup  time. 
While  neither  of  these  algorithms  completely  address  the  execution  scheduling  problem, 
they  contain  a  structure  and  methodology  close  enough  to  it  to  be  worth  much  more 
investigation. 

C.      SCHEDULING  DYNAMICS 

One  reason  the  heuristic  approaches  as  described  above  are  intuitively  appealing  for 
the  execution  scheduling  problem  is  that  they  are  capable  of  addressing  a  dynamic 
scheduling  process.  This  dynamic  process  is  characterized  by  two  factors.  The  first 
factor  is  the  incremental  approach  to  lift  scheduling.  In  a  situation  where  sealift  execution 
scheduling  is  required,  JDS  procedures  dictate  that  the  initial  schedule  be  developed  for 
the  first  30  days  of  deployment.  Following  the  development  of  that  increment,  the 
scheduling  horizon  is  increased  in  increments  of  at  least  one  day  of  lift.  The  size  of  the 
increase  is  not  otherwise  specified.    As  examined  above,  a  mathematical  programming 
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approach  cannot  satisfactorily  perform  in  such  a  situation.   Yet,  the  heuristic  approaches 
can  be  structured  to  handle  the  changing  schedule  size. 

The  second  factor  is  one  of  ship  allocation  uncertainty.  At  any  point  in  the 
scheduling  process,  there  may  not  be  enough  lift  assets  identified  to  schedule  lift  against. 
There  are  three  possible  methods  of  dealing  with  this  uncertainty.  The  first  is  the  one 
used  by  MSC  with  SEACOP.  If  lift  assets  are  not  known  when  SEACOP  is  run, 
intelligence  estimates  are  obtained  for  ship  locations.  From  those  estimates,  a  guess  is 
made  as  to  which  ships  will  be  allocated  for  sealift.  The  schedule  is  then  developed  using 
those  ships.  The  second  method  is  to  develop  notional  ships  that  are  representative  of  the 
type  of  ships  that  would  be  allocated.  The  notional  ships  are  then  used  for  scheduling. 
The  problem  with  these  two  approaches  is  that  if  the  ships  actually  allocated  are 
significantly  different  in  characteristics  from  those  used  for  scheduling,  recomputation  of 
the  entire  schedule  is  required.  This  is  not  an  efficient  way  to  schedule.  The  third  and 
more  reasonable  method  is  to  structure  the  scheduler  to  schedule  ships  dynamically  as 
they  are  allocated  for  sealift.  This  requires  some  dynamic  representation  of  the  cargo  to 
be  scheduled  to  facilitate  the  assignment  of  ships  as  they  are  allocated.  One  favorable 
consequence  of  this  approach  is  that  no  special  effort  is  required  to  incorporate  returning 
lift  assets  into  the  scheduling  process.  Once  an  asset  is  identified  as  returning,  it  can  be 
scheduled  against  the  unscheduled  cargo  given  its  projected  return  date.  This  structure 
would  be  amenable  to  the  heuristic  methods  described  previously,  though  further  work 
is  necessary,  especially  to  determine  the  best  algorithm  to  use,  especially  when  multiple 
ships  are  allocated  at  the  same  time. 

D.      RULES/CONSTRAINTS/PARAMETERS 

A  discussion  of  algorithmic  considerations  would  be  incomplete  without  closer 
examination  of  the  scheduling  rules  and  constraints  that  will  affect  an  execution 
scheduling  system.  Much  of  the  information  presented  here  is  drawn  from  factors 
incorporated  in  SEACOP  and  SEASTRAT  [Refs.  5,6].    While  these  packages  are  not 
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suited  to  the  execution   scheduling  problem,   their  identification  of  lift  scheduling 
constraints  is  reasonably  complete. 

1.  Cargo  Related  Constraints 

Cargo  characteristics  will  have  a  tremendous  effect  upon  the  scheduling 
process.  Cargo  volume  and  weight  characteristics  are  the  most  obvious,  but  many  special 
characteristics  exist  for  many  different  cargoes,  including  requirements  for  segregation, 
ammunition  restrictions,  containerization,  and  special  handling  equipment  [Ref.  4: pp. 
3-13  -  3-52].  Some  unit  loads  require  personnel  in  attendance.  The  assumption  that 
berthing  space  is  available  for  those  personnel  is  not  necessarily  a  reality.  Loading 
sequences  for  specific  priority  cargoes  may  be  specified  to  ensure  proper  offload  at  POD. 
Close  examination  of  the  TUCHA  file  and  Cargo  Category  Codes  will  be  required  to 
determine  the  significance  of  any  special  requirements  that  will  impact  scheduling. 

2.  Ship  Characteristics 

Obviously,  the  characteristics  of  the  lift  assets  available  are  critical  to  effective 
scheduling.  The  speed,  volume,  weight,  draft,  and  length  of  a  given  ship  are  required 
to  determine  what  cargoes  can  be  carried  and  which  ports  a  ship  might  operate  in. 
Generalization  by  ship  type  is  not  appropriate  since  there  is  wide  variation  in  those 
parameters  even  among  ships  of  a  single  type.  Another  consideration  is  one  of  mission. 
A  tanker  would  probably  not  be  best  utilized  in  carrying  ammunition  or  trucks.  A  non- 
self  sustaining  container  ship  needs  specific  crane  services  that  might  not  be  available  in 
smaller  ports  without  a  crane  ship  or  some  other  special  arrangement.  Speed  will  be  an 
area  where  the  NCSORG  will  have  an  impact.  The  maximum  speed  of  a  given  ship 
might  not  be  an  accurate  scheduling  parameter  if  that  ship  is  assigned  to  a  convoy  with 
a  lower  speed. 
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3.  Distance  Considerations 

Computation  of  distances  is,  for  the  most  part,  not  a  terribly  complex  problem. 
Some  provision  does  need  to  be  made  for  distance  computation  as  a  function  of  canal 
status.  If  the  Panama  Canal  is  not  available,  the  distance  between  the  Gulf  Coast  and 
Hawaii  or  California  becomes  much  greater.  One  aspect  of  this  computation  which  bears 
scrutiny  is  distance  generation  versus  distance  lookup.  SAIL  and  SEACOP  both  compute 
distances  at  run  time.  If  this  computation  is  slower  than  a  table  lookup  function,  then 
some  consideration  of  precomputing  distances  and  storing  them  for  lookup  might  be  in 
order,  so  long  as  means  remain  of  computing  distances  not  already  in  the  table.  Also 
included  under  distance  considerations  are  intermediate  stops  for  onload/offload  enroute 
and  NCSORG  track  routing. 

4.  Port  Considerations 

Port  impacts  upon  the  problem  can  be  significant.  Certain  ports  may  have 
draft/length  restrictions  or  may  not  have  the  special  handling  equipment  required  for 
certain  cargoes.  Throughput  at  a  given  port  might  be  constrained.  Unfortunately,  port 
selection  is  not  within  the  purview  of  the  sealift  scheduling  process  at  this  time.  MTMC 
selects  the  POE  for  a  load  and  MSC  determines  what  ship  should  be  assigned  to  that  load. 
If  POE  selection  becomes  a  sealift  scheduling  subproblem,  then  more  latitude  can  be 
given  to  the  initial  movement  of  a  load.  But,  for  the  time  being,  the  execution  scheduling 
system  is  only  concerned  with  whether  or  not  a  certain  ship  can  be  serviced  in  a  given 
port. 

5.  Time  Constraints 

The  three  TPFDD/JDS  specified  times  drive  the  time  windows  and  constraints 
for  the  execution  scheduling  problem.  The  ALD  indicates  the  date  that  the  cargo  is 
available  for  loading,  and  the  EAD  and  LAD  define  the  time  window  at  POD.  Other 
times  which  have  an  effect  on  the  ability  to  meet  those  times  are  ship  loading  times  and 
arrival  time  of  ships  at  the  POE  for  loading.   Again,  the  NCSORG  can  have  an  effect  in 
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that  convoying  can  severely  constrain  the  system's  ability  to  schedule  lift  to  arrive  within 
the  time  window  specified. 
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VI.  PROPOSED  SYSTEM  STRUCTURE 

Based  on  the  considerations  discussed  in  previous  chapters,  Figure  1  is  proposed  as 
the  structure  for  a  sealift  execution  scheduling  system.  This  structure  is  centered  around 
three  major  components.  The  scheduler  establishes  the  first  increment  of  lift,  given  the 
cargo  requirements  and  available  ships.  The  rescheduler  is  used  for  all  subsequent 
scheduling  tasks,  using  all  unscheduled  cargo,  unscheduled  ships,  and  partially  scheduled 
ships.  The  requirements  generator  is  used  to  examine  lift  shortfalls  and  determine 
requirements  for  ships  that  can  be  used  to  make  a  request  of  MarAd  for  additional  assets. 
This  is  a  broad,  high-level  system  specification.  It  lacks  the  detail  necessary  to  produce 
a  complete  scheduling  system.  The  point  of  this  structure  is  to  provide  a  framework  upon 
which  intelligent  research  and  detailed  system  design  can  be  founded. 

A.      INITIAL  SCHEDULER 

The  initial  scheduler,  as  proposed  and  shown  in  Figure  2,  will  be  a  first  pass,  single 
pass  scheduler.  It  will  be  used  to  compute  the  schedule  for  the  first  increment  of  sealift, 
given  the  ships  actually  allocated.  This  is  one  possible  place  where  a  mathematical 
programming  approach  might  be  a  viable  technique,  so  long  as  some  provision  is  made 
for  allowing  cargo  to  remain  unscheduled  if  there  are  no  lift  assets  available  to  move  it. 
In  mathematical  programming  this  is  typically  accomplished  by  adding  a  dummy  variable 
to  the  formulation.  In  this  case,  a  dummy  ship  would  have  to  be  established  and  the 
formulation  would  need  to  be  structured  so  that  only  cargoes  without  a  viable  lift  asset 
available  would  be  assigned  to  the  dummy  ship.  Cargoes  that  have  a  good  assignment 
must  be  protected  from  assignment  to  the  dummy  ship.  This  is  not  an  easy  formulation. 
In  a  such  a  situation,  the  dummy  ship  would  have  to  have  large  capacity  to  allow  for  all 
of  the  possible  unscheduled  cargoes,    yet  it  would  have  to  have  a  high  usage  cost  to 
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Figure  1  Proposed  System  Structure 
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prevent  it  from  being  chosen  over  an  actual  ship.  This  dummy  ship  would  also  have  to 
be  structured  to  allow  for  clear  identification  of  the  cargoes  assigned  to  it.  This  would 
then  be  the  unscheduled  cargo  output  as  shown  in  Figure  2.  This  topic  has  to  be  studied 
in  much  greater  detail.  Even  with  the  reasonably  static  nature  of  the  initial  scheduler, 
a  heuristic  approach  may  still  be  required  to  meet  the  output  and  reporting  requirements. 
Another  stipulation  that  could  affect  the  structure  of  the  initial  scheduler  is  the  size 
and  scheduling  of  the  first  increment.  For  the  reasons  discussed  in  the  previous  chapter, 
it  is  more  sensible  to  schedule  ships  only  as  they  are  allocated.  This  might  preclude 
complete  scheduling  of  the  first  increment  in  the  time  frame  specified  by  the  JDS 
Procedures  Manual  [Ref.  3]  if  sufficient  lift  assets  are  not  identified  and  allocated  early 
in  the  scheduling  process.  The  two  artificial  approaches,  the  intelligence  estimate  and  the 
notional  ships,  in  truth,  do  not  meet  this  requirement  either  because  the  schedules  based 
on  those  approaches  are  notional,  not  actual.  In  this  light,  the  initial  scheduler  should  not 
be  compelled  to  produce  a  completely  scheduled  first  increment.  Rather,  it  should  take 
the  assets  available  and  schedule  them  within  the  30  day  window  required  for  that 
increment.  If  the  structure  of  JDS  requires  a  complete  schedule,  the  JDS  database  should 
be  modified  to  relax  this  requirement,  especially  since  any  complete  schedule  developed 
under  these  conditions  would  be  artificial  at  best. 

B.      RESCHEDULE!* 

The  rescheduler,  for  lack  of  a  better  term,  will  be  the  scheduling  work  horse  of  the 
system.  As  shown  in  Figure  1  and  Figure  3,  the  rescheduler  will  be  the  iterative  part  of 
the  scheduler,  dealing  with  changes  in  cargoes,  ships,  and  the  increase  in  the  scheduling 
window  due  to  the  incremental  scheduling  process.  This  is  the  portion  of  the  execution 
process  that  will  be  heavily  dependent  upon  carefully  conceived  and  implemented  heuristic 
solution  techniques,  such  as  the  time-windows  algorithms  discussed  earlier.  As  seen  in 
Figure  3,  there  will  be  essentially  four  categories  of  input.  The  two  cargo  categories  will 
be  composed  of  cargo  unscheduled  in  previous  passes  and  new  cargo  added  to  the 
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problem  as  a  result  of  the  increasing  scheduling  window.  The  two  ship  categories  will 
be  based  on  unused  capacity  from  previous  passes  and  that  capacity  added  either  by  new 
ships  or  ships  returning  for  subsequent  assignment  after  performing  a  previous  lift 
mission.  The  three  output  categories  of  this  module  will  be  scheduled  ships/cargo, 
unscheduled  cargo  for  consideration  in  another  pass,  and  unscheduled  or  partially 
scheduled  ships  available  for  another  pass.  For  the  partially  scheduled  ships,  some 
determination  must  be  made  as  to  whether  or  not  its  remaining  capacity  will  be  made 
available  if  such  availability  will  impact  the  feasibility  of  meeting  the  delivery  window 
of  the  cargoes  already  loaded.  This  is  where  the  quality  of  the  heuristic  algorithms 
selected  will  be  critical.  If  the  ship  loading  and  assignment  criteria  are  not  good,  ships 
will  be  poorly  loaded  and  a  large  amount  of  cargo  will  remain  unscheduled.  In  an  asset 
scarce  and  time-critical  deployment  this  is  clearly  not  acceptable. 

In  this  light,  some  sort  of  a  broad,  best- fit  approach  might  be  best.  As  a  ship  is  up 
for  assignment,  the  unscheduled  requirements  are  searched  for  the  best  and  most  efficient 
loading,  where  the  criteria  for  a  best  fit  include  the  time  windows,  loading,  and  cargo 
priority  considerations.  This  is  obviously  a  complex  question,  deserving  much  more 
study  before  an  effective  solution  can  be  implemented. 

C.      REQUIREMENTS  GENERATOR 

If,  in  fact,  lift  assets  will  be  scarce  or  slow  in  coming,  some  means  must  be  made 
available  to  estimate  the  shortfall  in  lift  capacity  under  execution  and  characterize  that 
shortfall  in  terms  of  ships  required.  Figure  4  shows  the  structure  of  such  an  estimator. 
In  this  case,  some  application  of  notional  capacities  is  appropriate  in  that  those  capacities 
will  only  be  utilized  for  the  purpose  of  determining  the  number  and  type  of  ships  that 
MarAd  will  be  requested  to  provide  for  the  execution  effort.  Inputs  to  this  module  will 
be  the  remaining  unscheduled  cargo  and  known  returning  ships.  With  respect  to  known 
returning  ships,  a  decision  will  have  to  be  made  as  to  where  in  the  return  cycle  a  ship  will 
be  designated  as  known  returning.    The  potential  impact  here  is  that  if  a  ship  that  has 
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been  so  designated  is  attrited  during  the  return  cycle,  the  lift  shortfall  will  be  more  severe 
than  planned  for.  This  is  balanced  against  the  recognition  that  the  earlier  an  asset  can  be 
planned  against,  the  more  effective  and  timely  the  scheduling  process.  This  is  a 
consideration  that  will  have  to  be  based  on  the  threat  and  probability  of  attrition  during 
execution. 

The  notional  characteristics  to  be  used  for  this  generator  can  potentially  come  from 
several  sources.  There  are  notional  ship  parameters  that  have  been  incorporated  as 
planning  factors  in  the  Joint  Strategic  Capabilities  Plan  (JSCP),  but  they  were  unavailable 
at  this  writing.  JCS  policy  prohibits  the  release  of  planning  factors  to  DoD  schools, 
though  hopefully  they  could  be  made  available  to  a  scheduling  system  developer.  Another 
possible  way  to  derive  notional  capacities  would  be  to  use  some  sort  of  a  broad  measure 
across  several  ships  and  ship  types.  Such  derivation,  while  not  desirable  for  actual 
scheduling,  might  be  sufficient  for  developing  a  request  for  additional  shipping.  This 
segment  is  also  where  the  nature  of  the  external  interface  with  MarAd  comes  into 
question.  If  a  large  request  is  to  be  made  of  MarAd,  the  single  secure  teletype  might  not 
be  sufficient  for  communicating  those  requirements  to  MarAd  or  for  MarAd' s  response. 
These  questions  will  all  be  contingent  upon  the  size  of  the  OPLAN  to  be  executed  and  the 
required  lift  capacity. 
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Vn.  CONCLUSIONS  AND  RECOMMENDATIONS 

This  analysis  of  sealift  execution  scheduling  requirements  is  by  no  means  complete. 
Rather,  it  is  a  broad  first  attempt  at  defining  and  quantifying  an  important  and  complex 
problem.  As  has  been  mentioned  previously,  significant  work  remains,  particularly  in  the 
examination  and  development  of  an  appropriate  scheduling  algorithm.  One 
recommendation  for  such  development  is  to  contract  for  algorithmic  research  prior  to 
contracting  for  an  entire  system.  This  would  ensure  proper  development  of  the  most 
critical  component  of  the  scheduling  system.  The  remainder  of  the  system  could  then  be 
designed  and  developed  around  that  scheduler.  One  problem  with  concurrent 
development  of  a  system  and  a  scheduler  is  that  critical  operational  aspects  of  a  scheduler 
may  have  to  be  compromised  in  order  to  make  it  compatible  with  the  overall  system. 
Prior  development  of  the  scheduler  minimizes  this  problem.  If  the  scheduler  is  accorded 
the  requisite  developmental  priority  and  recognized  software  design  concepts  are  followed, 
stressing  early  identification  of  interfaces,  modularity,  and  complete  problem  definition 
prior  to  development,  then  an  effective  sealift  execution  scheduling  system  can  be 
realized. 

Given  that  the  development  and  completion  of  an  execution  scheduling  system  will 
probably  not  be  a  near-term  reality,  some  interim  measures  to  improve  execution 
scheduling  are  in  order.  The  first  step  is  to  improve  the  level  of  JDS  support  provided 
to  MSC.  This  improvement  includes  training  and  dedicated  programming  support  from 
USTRANSCOM.  Such  support  has  been  provided  in  the  past  to  MSC  and  the  area 
commands  in  a  sporadic  and  piecemeal  fashion.  For  example,  a  change  to  the  JDS 
database  implemented  in  the  fall  of  1988  rendered  a  number  of  specialized  database 
retrievals  useless  to  MSCPAC.  This  significantly  reduced  scheduling  efficiency  and 
limited  the  use  of  a  locally  developed  BASIC  program  used  to  sort  and  aggregate  lift 
requirements.    Second  or  third  hand  JDS  support  through  OPNAV  is  not  sufficient.    It 
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does  not  seem  unreasonable  that  USTRANSCOM  should  provide  specialized  JDS  support 
to  one  or  all  of  the  TOAs  that  it  is  responsible  for,  especially  since  such  support  would 
increase  overall  mission  capability. 

Another  area  where  short-term  improvement  could  be  realized  is  in  electronic  data 
transfer,  both  internally  and  externally.  Internally,  an  effort  must  be  made  to  resolve  the 
electronic  media  entry  security  problem  with  the  WIN  sites.  It  makes  little  sense  to 
collect  scheduling  information  online,  then  be  required  to  print  it  out  for  manual  entry  by 
keyboard  in  the  WIN  site.  This  problem  needs  to  be  addressed  from  the  standpoint  of 
allowing  the  entry  of  media  containing  information  without  compromising  WIN  security. 
This  problem  cannot  be  ignored  if  a  swift  and  effective  scheduling  process  is  to  be 
developed.  Externally,  the  initiatives  for  improving  data  communications  between  the 
MTMC  and  MSC  area  commands  could  improve  the  overall  process.  The 
communications  improvements  discussed  in  Chapter  IV  are  not  strictly  tied  to 
development  of  a  specific  scheduling  system.  Improved  coordination  and  information 
transfer  could  easily  be  realized  if  such  a  communications  interface  were  established. 

Sealift  execution  scheduling  is  a  large,  complex  process,  dependent  upon  a  myriad 
of  factors.  While  algorithmic  considerations  are  a  significant  portion  of  the  problem,  all 
of  the  factors  and  processes  impacting  upon  lift  scheduling  must  be  evaluated  and 
accounted  for.  The  ability  to  effectively  and  efficiently  schedule  lift  is  crucial  to  this 
nation's  strategic  mobilization  capability.   It  has  to  be  done  right. 
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GLOSSARY  OF  TERMS 

The  definitions  contained  herein  are  drawn  from  NWP  80  [Ref.  1],  The  Joint  Staff 
Officer's  Guide  [Ref.  2],  and  the  JDS  Users  Data  Element  Dictionary  [Ref.  4].  Consult 
these  references  for  other  terms  or  further  definition  of  the  terms  below. 

Available  to  Load  Date  (ALD):  A  date  specified  for  each  unit  in  the  TPFDD  indicating 
the  earliest  a  cargo  may  begin  loading  at  the  port  of  embarkation.  [Ref.  2] 

Cargo  Category  Codes  (CCC):  A  three  letter  cargo  identifier  which  provides  descriptive 
information  as  to  type,  size,  and  transportation  mode  required.  [Ref.  4] 

Course  of  Action  (CO A):  A  possible  plan  open  to  an  individual  or  commander  that 
would  accomplish  or  is  related  to  the  accomplishment  of  a  mission.  [Ref.  2] 

Crisis  Action  Procedures  (CAP):  See  Crisis  Action  System. 

Crisis  Action  System  (CAS):  A  system  specified  in  JCS  Pub  5-02.4  that  gives  guidance 
and  procedures  for  joint  operation  planning  by  military  forces  during  emergency  or  time- 
sensitive  situations.  The  procedures  are  designed  to  give  the  Chairman  of  the  Joint  Chiefs 
of  Staff  information  to  develop  timely  recommendations  to  the  National  Command 
Authority  for  decisions  involving  the  use  of  U.S.  military  forces.  [Ref.  2] 

C-Day:  The  day  on  which  movement  from  origin  begins  or  is  to  begin.  The  deployment 
may  be  movement  of  troops,  cargo,  weapon  systems,  or  a  combination  of  these  elements 
using  any  or  all  types  of  transportation.  For  planning,  C-Day  remains  unnamed,  but 
under  execution,  C-Day  is  established  under  the  authority  and  direction  of  the  Secretary 
of  Defense.  [Ref.  2] 

D-Day:  The  day  on  which  a  particular  operation  begins  or  is  scheduled  to  begin.  This 
operation  may  be  land  assault,  air  strike,  naval  bombardment,  parachute  assault,  or 
amphibious  assault.  [Ref.  2] 

Earliest  Arrival  Date  (EAD):  A  day,  relative  to  C-Day,  specified  by  the  planner  as  the 
earliest  date  a  cargo  can  be  accepted  at  a  port  of  debarkation.  [Ref.  2] 
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Effective  U.S.  Control  Fleet  (EUSC):  U.S.  citizen  owned  shipping  registered  and 
operated  under  a  flag  of  convenience. 

Flag  of  Convenience  :  Merchant  ship  registration  in  countries  where  owner  citizenship 
is  not  required  and  significant  economic  and  operating  benefits  are  realized  through  such 
registry. 

Joint  Strategic  Capabilities  Plan  (JSCP):  The  JSCP  contains  the  military  strategy  to 
support  the  national  security  objectives  and  the  derived  military  objectives.  It  gives 
guidance,  based  on  projected  military  capabilities  and  conditions  during  the  short  rang 
period,  and  task  assignments  to  the  unified  and  specified  Commanders  in  Chief  and  Chiefs 
of  the  Services  for  the  accomplishment  of  military  tasks.  It  apportions  forces  and  lift 
assets  for  planning.  [Ref.  2] 

Joint  Chiefs  of  Staff  (JCS):  The  Chairman,  the  Chief  of  Staff  of  the  Army,  the  Chief 
of  Naval  Operations,  the  Chief  of  Staff  of  the  Air  Force,  and  the  Commandant  of  the 
Marine  Corps.  [Ref.  2] 

Joint  Deployment  System  (JDS):  Personnel,  procedures,  directives,  communications 
systems,  and  electronic  data  processing  systems  that  directly  support  time-sensitive 
planning  and  execution  and  complement  peacetime  deliberate  planning  by  disseminating 
deployment  information.  [Ref.  2] 

Joint  Deployment  Community  (JDC):  Those  headquarters,  commands,  and  agencies 
involved  in  training,  preparation,  movement,  reception,  employment,  support,  and 
sustainment  of  military  forces  assigned  or  committed  to  a  theater  of  operations.  The  JDC 
normally  consists  of  the  JCS  Joint  Staff,  Services,  unified  and  specified  combatant 
commands  including  USTRANSCOM,  and  defense  agencies  as  appropriate  to  a  given 
scenario.  [Ref.  2] 

Latest  Arrival  Date  (LAD):  A  day,  relative  to  C-day,  specified  by  the  planner  as  the 
latest  date  a  cargo  can  be  accepted  at  a  port  of  debarkation.  [Ref.  2] 

Maritime  Administration  (Mar Ad):  The  unit  of  the  Department  of  Transportation 
designated  to  develop,  promote,  and  maintain  the  U.S.  merchant  marine.  MarAd  is 
responsible  for  the  RRF,  NDRF,  and  in  war  as  the  National  Shipping  Authority,  for 
requisitioning  merchant  shipping  to  support  mobilization.  [Ref.  7] 

Measurement  Ton  (MTon):  A  volumetric  measure  of  cargo  equivalent  to  40  cubic  feet 
of  volume.  [Ref.  1] 

Military  Sealift  Command,  Atlantic  (MSCLANT):  The  MSC  area  command  with 
responsibility  for  the  Atlantic  area. 
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Military  Sealift  Command,  Pacific  (MSCPAC):  The  MSC  area  command  with 
responsibility  for  the  Pacific  area. 

Military  Airlift  Command  (MAC):  The  single  management  agency  within  the 
Department  of  Defense  responsible  for  air  transportation. 

Military  Sealift  Command  (MSC):  The  single  management  agency  within  the 
Department  of  Defense  responsible  for  ocean  transportation.  [Ref.  1] 

Military  Traffic  Management  Command  (MTMC):  The  single  management  agency 
within  the  Department  of  Defense  responsible  for  management  of  DoD  cargo  movements 
within  the  Continental  United  States.  [Ref.  17] 

National  Command  Authorities  (NCA):  The  President  and  the  Secretary  of  Defense  or 
their  duly  deputized  alternates  or  successors.  [Ref.  2] 

National  Shipping  Authority   (NSA):  The  emergency  shipping  operations  agency 
established  out  of  MarAd  in  time  of  war  to  acquire  and  manage  merchant  shipping. 
[Ref.  1] 

National  Defense  Reserve  Fleet  (NDRF):  A  fleet  of  ships  acquired  and  maintained  by 
MarAd  for  use  in  mobilization  or  emergency.  The  NDRF  less  the  RRF  is  composed  of 
older  ships  maintained  at  a  relatively  low  level  of  readiness,  available  only  on 
mobilization  or  Congressional  declaration  of  emergency.  [Ref.  1] 

Naval  Control  of  Shipping  Organization  (NCSORG):  The  organization  that  in  time  of 
war  or  national  emergency  exercises  authority  for  the  control  and  direction  of  actual 
merchant  ship  movement.  [Ref.  1] 

N-Day:  A  day  prior  to  C-Day.   N002  would  reflect  a  day  two  days  before  C-Day. 
[Ref.  2] 

Operation  Plan  (OPLAN):  Any  plan  prepared  for  the  conduct  of  military  operations  in 
a  hostile  environment  by  the  commander  of  a  unified  or  specified  command  in  response 
to  a  requirement  established  by  the  Chairman  of  the  Joint  Chiefs  of  Staff.  [Ref.  2] 

Operation  Order  (OPORD):  A  directive  issued  by  a  commander  to  subordinate 
commanders  for  effecting  coordinated  execution  of  an  operation.  [Ref.  2] 

Operational  Control  Authority  (OCA):  The  naval  commander  responsible  for  the 
control  of  movements  and  the  protection  of  allied  merchant  ships  within  a  specified 
geographical  limit.  [Ref.  1] 
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Port  of  Embarkation  (POE):  The  geographic  point  in  the  routing  scheme  where  a 
movement  requirement  will  begin  its  strategic  deployment.  [Ref.  2] 

Port  of  Debarkation  (POD):  The  geographic  point  in  the  routing  scheme  where  a 
movement  requirement  will  complete  its  strategic  deployment.  [Ref.  2] 

Ready  Reserve  Force  (RRF):  A  portion  of  the  NDRF  composed  of  ships  acquired  by 
Mar  Ad  with  Navy  funding  or  for  the  NDRF  maintained  in  a  higher  state  of  readiness  and 
available  for  service  without  mobilization  or  Congressional  declaration  of  emergency. 
[Ref.  1] 

Sealift  Readiness  Program  (SRP):  A  formal  agreement  between  MSC  and  U.S.  flag 
ocean  carriers  for  acquisition  of  ships  and  related  equipment  under  conditions  of  less  than 
full  mobilization.  [Ref.  1] 

Sealift  Strategic  Planning  System  (SEASTRAT):  MSC's  newest  deliberate  planning 
system  for  sealift.   SEASTRAT  is  programmed  as  a  replacement  for  SEACOP. 

Strategic  Algorithm  for  Improving  Lift  (SAIL):  SAIL  is  the  sealift  scheduling  module 
contained  within  SEASTRAT. 

Strategic  Sealift  Contingency  Planning  System  (SEACOP):  MSC's  1970  era  deliberate 
planning  system  for  sealift. 

Supported  Command/Commander:  The  commander  who  originates  operation  plans  in 
response  to  requirements  of  the  Chairman  of  the  Joint  Chiefs  of  Staff.  In  an  employment 
scenario,  the  supported  commander  will  be  the  commander  tasked  with  executing  a  given 
course  of  action.  [Ref.  2] 

Supporting  Command/Commander:  A  commander  who  furnishes  augmentation  forces 
or  other  support  to  a  supported  commander.  [Ref.  2] 

Time  Phased  Force  Deployment  Data  (TPFDD):  The  computer-supported  portion  of  an 
OPLAN  that  contains  time-phased  force  data,  non-unit-related  cargo,  and  personnel  data, 
and  movement  data  for  the  OPLAN.  Information  includes  in-place  units,  prioritized 
arrival  of  units  deployed  to  support  the  OPLAN,  etc.  [Ref.  2] 

Transportation  Operating  Agencies  (TO A):  Military  Traffic  Management  Command 
(MTMC),  Military  Sealift  Command  (MSC),  and  Military  Airlift  Command  (MAC). 

Type  Unit  Data  File  (TUCHA):  A  files  that  gives  standard  planning  data  and  movement 
characteristics    for   personnel,    cargo,    and   accompanying    supplies   associated    with 
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deployable  type  units  of  fixed  composition.  The  file  contains  the  weight  and  volume  of 
selected  cargo  categories,  physical  characteristics  of  the  cargo,  and  the  number  of 
personnel  requiring  non-organic  transportation.  (A  person  assigned  to  a  destroyer  would 
be  considered  to  have  organic  transportation.)  [Ref.  2] 

U.S.  Transportation  Command  (USTRANSCOM):  The  unified  combatant  command 
for  transportation  missions,  responsibilities,  and  the  forces  of  MTMC,  MSC,  and  MAC. 
[Ref.  18] 

Voluntary  Tanker  Agreement  (VTA):  Procedures  for  voluntary  contribution  of  tanker 
capacity  by  commercial  tanker  owners  and  operators  administered  by  MarAd.  [Ref.  1] 

World  Wide  Military  Command  and  Control  System  (WWMCCS):  The  system  that 
provides  the  means  for  operational  direction  and  technical  administrative  support  involved 
in  the  function  of  command  and  control  of  U.S.  military  forces.  [Ref.  2] 

WWMCCS  Intercomputer  Network  (WIN):  The  system  that  provides  for  remote  access 
and  data  transfer  between  users  within  WWMCCS.  [Ref.  2] 
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